On Tue, Feb 9, 2016 at 12:35 PM, Hardy Family <hardy.woodland.cypress@...> wrote:

Hi Tom,

I now have some time to try to implement the FRO shuttle mode that was mentioned in the "worth supporting native arcs" thread.  A few questions (quite a few, actually :-):

1. CS0_TimeExecuted+CS0_t is the total coordinated motion ever executed, starting from 0.0 at boot time, no?  So if I subtract CS0_TimeLost from that, then is that the available amount of motion buffered up to the current point?  So I know how far back I can go, hopefully.  Then I can also tell how much motion is forward, by comparing to CS0_TimeDownloaded, no?

2. Should I use SetFROTemp() instead of SetFRO()?  I don't want to distinguish between rapid and normal moves, and it should not alter the FRO selected by the user.

3. When terminating this mode, to go back to the user-selected FRO, should I do SetFRO(CS0_LastFRO) and SetRapidFRO(CS0_LastRapidFRO)?

3a. What would be the best way to cancel any forward motion?  For example, the user backs up, but does not want to re-do the buffered forward motion.

4. I'm worried about how this is going to interact with locally induced motion e.g. Move() calls etc.  We use these for tool change, probing etc.  I would guess that these, being outside the normal coordinated motion stream, are going to causes problems with the simple shuttle scheme, since there will be "jumps" in the CM buffer.  So basically I will need to be careful to put some sort of "time fence" at points where local motion is inserted, so that the shuttle motion will not try to go beyond those points.

5. Similar to the above, what about points in the buffer where the PC was not sending continuous motion e.g. was waiting for some user input or an M code to complete?  How am I going to tell that some part of the buffer was just "idle time" (if that is even stored, or maybe those intervals don't even exist)?

Regards,

SJH

On Tue, Feb 9, 2016 at 4:19 PM, Hardy Family <hardy.woodland.cypress@...> wrote:

Well I tried using SetFROTemp() but it seems to ignore a negative feed rate.

It has the unfortunate effect that when the G-code program starts running, the interpreter sends out a SetFRO() so that the machine starts moving even though it is supposedly in "shuttle" mode.  I think that's because my FRO control loop will immediately start trying to pull the FRO negative, since the target time is then behind the current position.  But if the SetFROTemp() ignores negatives, then the machine continues to run in real-time.  I have to then restart the shuttle mode to stop the machine.

Another unrelated problem is when the interpreter finishes, it sits there waiting even if I shuttle the machine to the end of motion.  Only when shuttle mode is terminated (and it calls SetFRO(CS0_LastFRO)) does the interpreter finish up.

Regards,

SJH

On Tue, Feb 9, 2016 at 12:35 PM, Hardy Family <hardy.woodland.cypress@...> wrote:

Hi Tom,

I now have some time to try to implement the FRO shuttle mode that was mentioned in the "worth supporting native arcs" thread.  A few questions (quite a few, actually :-):

1. CS0_TimeExecuted+CS0_t is the total coordinated motion ever executed, starting from 0.0 at boot time, no?  So if I subtract CS0_TimeLost from that, then is that the available amount of motion buffered up to the current point?  So I know how far back I can go, hopefully.  Then I can also tell how much motion is forward, by comparing to CS0_TimeDownloaded, no?

2. Should I use SetFROTemp() instead of SetFRO()?  I don't want to distinguish between rapid and normal moves, and it should not alter the FRO selected by the user.

3. When terminating this mode, to go back to the user-selected FRO, should I do SetFRO(CS0_LastFRO) and SetRapidFRO(CS0_LastRapidFRO)?

3a. What would be the best way to cancel any forward motion?  For example, the user backs up, but does not want to re-do the buffered forward motion.

4. I'm worried about how this is going to interact with locally induced motion e.g. Move() calls etc.  We use these for tool change, probing etc.  I would guess that these, being outside the normal coordinated motion stream, are going to causes problems with the simple shuttle scheme, since there will be "jumps" in the CM buffer.  So basically I will need to be careful to put some sort of "time fence" at points where local motion is inserted, so that the shuttle motion will not try to go beyond those points.

5. Similar to the above, what about points in the buffer where the PC was not sending continuous motion e.g. was waiting for some user input or an M code to complete?  How am I going to tell that some part of the buffer was just "idle time" (if that is even stored, or maybe those intervals don't even exist)?

Regards,

SJH

On Sun, Feb 14, 2016 at 2:16 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

Hi SJH,

"Feeding" in negative time should be supported.  KMotionCNC does it with the code below by sending the SetFROTemp script command which should be exactly the same as the function call.

void CForRevButton::HandleButtonDown(void)
{
    CString s;
    CCoordMotion *CM= Dlg->Interpreter->CoordMotion;

    // FRO in direction

    if (!Dlg->m_Simulate)
    {
        s.Format("SetFROTemp %.4f",m_dir * m_mag);
        if (TheFrame->KMotionDLL->WriteLine(s)) return;
        m_Moving=true;
    }
}


You might debug it by printing the internal variables/functions:

Here is some related internal code:

void SetFROTemp(float FRO)
{
    SetFROwRateTemp(FRO,GetNominalFROChangeTime());
}

// change from current to the specified FRO (FRO=1.0=Realtime)
// using a rate based on caller specified time to change from 1.0 to 0.0

void SetFROwRateTemp(float FRO, float DecelTime)
{
    if (DecelTime < 1e-6)DecelTime=1e-6;
    CS0_TimeBaseDelta = TIMEBASE*TIMEBASE/DecelTime;
    CS0_TimeBaseDesired = FRO * TIMEBASE;
}

HTH
Regards
TK

On 2/14/2016 1:44 PM, Hardy Family hardy.woodland.cypress@... [DynoMotion] wrote:

 

Hi Tom,

you might have missed this, but anyway it is mostly working except that I cannot set a negative rate in SetFROTemp().  If it can't really go backwards then I can live with that, but if it is possible then I would like to get it working.

Regards,

SJH

On Tue, Feb 9, 2016 at 4:19 PM, Hardy Family <hardy.woodland.cypress@...> wrote:

Well I tried using SetFROTemp() but it seems to ignore a negative feed rate.

It has the unfortunate effect that when the G-code program starts running, the interpreter sends out a SetFRO() so that the machine starts moving even though it is supposedly in "shuttle" mode.  I think that's because my FRO control loop will immediately start trying to pull the FRO negative, since the target time is then behind the current position.  But if the SetFROTemp() ignores negatives, then the machine continues to run in real-time.  I have to then restart the shuttle mode to stop the machine.

Another unrelated problem is when the interpreter finishes, it sits there waiting even if I shuttle the machine to the end of motion.  Only when shuttle mode is terminated (and it calls SetFRO(CS0_LastFRO)) does the interpreter finish up.

Regards,

SJH

On Tue, Feb 9, 2016 at 12:35 PM, Hardy Family <hardy.woodland.cypress@...> wrote:

Hi Tom,

I now have some time to try to implement the FRO shuttle mode that was mentioned in the "worth supporting native arcs" thread.  A few questions (quite a few, actually :-):

1. CS0_TimeExecuted+CS0_t is the total coordinated motion ever executed, starting from 0.0 at boot time, no?  So if I subtract CS0_TimeLost from that, then is that the available amount of motion buffered up to the current point?  So I know how far back I can go, hopefully.  Then I can also tell how much motion is forward, by comparing to CS0_TimeDownloaded, no?

2. Should I use SetFROTemp() instead of SetFRO()?  I don't want to distinguish between rapid and normal moves, and it should not alter the FRO selected by the user.

3. When terminating this mode, to go back to the user-selected FRO, should I do SetFRO(CS0_LastFRO) and SetRapidFRO(CS0_LastRapidFRO)?

3a. What would be the best way to cancel any forward motion?  For example, the user backs up, but does not want to re-do the buffered forward motion.

4. I'm worried about how this is going to interact with locally induced motion e.g. Move() calls etc.  We use these for tool change, probing etc.  I would guess that these, being outside the normal coordinated motion stream, are going to causes problems with the simple shuttle scheme, since there will be "jumps" in the CM buffer.  So basically I will need to be careful to put some sort of "time fence" at points where local motion is inserted, so that the shuttle motion will not try to go beyond those points.

5. Similar to the above, what about points in the buffer where the PC was not sending continuous motion e.g. was waiting for some user input or an M code to complete?  How am I going to tell that some part of the buffer was just "idle time" (if that is even stored, or maybe those intervals don't even exist)?

Regards,

SJH